Overlay packet data network for managing energy and method for using same

ABSTRACT

A system for managing energy, comprising a processor coupled to a packet data network and a serves software module executing on the processor is disclosed, wherein the server software module is adapted to send and receive information over a packet data network from a plurality of client software modules associated with energy load devices or energy generating devices associated with one or more end users of energy provided by an energy distribution network, and to send and receive information from a plurality of software modules associated with energy distribution networks over the packet data network. At least some of the information sent from the server software module to the software modules associated with energy distribution networks is based at least in part on information received from one or more of the client software modules, and at least some of the information sent to the client software modules is based at least in part on information received from at least one of the software modules associated with energy distribution networks.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to Provisional Application Ser. No.61/208,770, filed on Feb. 26, 2009, and is a continuation-in-part ofPatent Application Ser. No. 12/383,993, filed on Mar. 30, 2009, thespecifications of both of which are hereby incorporated in theirentirety by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention is in the field of energy management, and inparticular in the subfield of smart grid systems. Yet more particularly,the present invention pertains to systems for managing distributedenergy resources.

2. Discussion of the State of the Art

While a robust electric power grid is widely recognized as a vitalinfrastructure component of a developed economy, technological progressin the field of electricity grid systems has not kept up with the paceof other important technological fields such as telecommunications. Mostof the electric grid infrastructure has been in place for decades, andthe basic architecture conceived by Thomas Edison and enhanced by thelikes of George Westinghouse and Samuel Insull still prevails.Additionally, the current regulatory scheme in the United Statesdiscourages large-scale investment in transmission and distributioninfrastructure, with the unfortunate result that the grid is oftenrunning near capacity.

A number of techniques have been devised to assist in maintaining gridstability during times of high stress, which normally means peak usagehours but also includes periods during normal usage when part of thegrid goes offline, thus reducing the effective capacity of the grid or aregion of it. It is commonplace for “peaking generators”, often operatedby independent power producers, to be placed online at peak periods togive the grid greater capacity; since periods of high demand tend tolead to high wholesale power prices, the business model of peakinggenerator operators is premised on operating their generators only whenthe price that can be obtained is high. Large utilities, desiring toavoid the use of high-priced peaking generators when possible, alsoroutinely participate in demand response programs. In these programs,arrangements are made by independent third parties with largecommercial, industrial, or institutional users of power to give controlto the third parties over certain electric loads belonging to largeusers. These third parties make complementary arrangements with electricutilities to provide “negative load” during peak periods, on demand, byshedding some portion of the loads under their control when requested bythe utility. Typically the cost to the utility of paying theseaggregators of “megawatts” (negative megawatts, or negative loadavailable on demand) is much less than the corresponding costs theutilities pay to peak generators for actual megawatts. That is, theutilities pay for “dispatchable load reduction” instead of for“dispatchable peak generation”, and they do so at a lower rate. Thisarrangement is attractive to the utilities not only because of theimmediate price arbitrage opportunity it presents, but also because, byimplementing demand reduction, the utilities are often able to deferexpensive capital improvements which might otherwise be necessary toincrease the capacity of the grid.

A problem with the current state of the art in demand reduction is thatit is only practical, in the art, to incorporate very large users indemand reduction programs. Large commercial and industrial users ofelectricity tend to use far more power on a per-user basis than smallcommercial and residential users, so they have both the motive (largesavings) and the means (experienced facilities management) to takeadvantage of the financial rewards offered by participation in demandmanagement programs. Additionally, large users of electricity alreadyare accustomed to paying a price for power that depends on marketconditions and varies throughout the day, and they often have alreadyinvested in advanced building automation systems to help reduce the costof electricity by conserving.

Unfortunately, a large portion (roughly 33%) of the electric power usedduring peak periods goes to small users, who do not normally participatein demand management. These users often are unaware of their energyusage habits, and they rarely pay for electricity at varying rates.Rather, they pay a price per unit of electricity used that is tightlyregulated and fixed. Partly this is due to the fact that the largemajority of small businesses and homes do not have “smart meters”; theamount of power used by these consumers of electricity is measured onlyonce per month and thus there is no way to charge an interval price(typically pricing is set at intervals of 15 minutes when intervalpricing is in effect) that varies based on market conditions.Furthermore, the loads in the homes and businesses of small electricityusers are invisible to the utilities; it is generally not possible forutilities to “see”, much less to control, loads in homes and smallbusinesses. Loads here refers to anything that uses electricity,including but not limited to lighting, heating ventilation and airconditioning (HVAC), hot water, “white goods” (large appliances such aswashers, driers, refrigerators and the like), hot tubs, computers, andso forth.

One approach in the art to improving the situation with small users isto install smart meters at homes small businesses. While the primarymotivation for doing so is to enable interval-based usage measurementand the communication of interval-based prices to the users, it is alsopossible to provide the consumer with much more information on how sheuses energy than was possible without a smart meter. Given this granularusage information, utilities and some third parties also hope to be ableto send signals, either via pricing or “code red” messages (which askconsumers to turn off unnecessary loads due to grid constraints), orboth. In some cases, third parties seek to provide visibility andcontrol to utilities so that, when consumers allow it, the utilities canturn loads off during peak demand to manage the peak. A related methodinvolves the use of “gateway” devices to access a consumer's (again,referring to residences, businesses, and institutions) home areanetworks (HAN) to communicate with or turn off local devices.

It is a disadvantage of the techniques known in the art that theconsumers and small businesses are not, in general, provided with anysubstantial financial incentives to participate in demand reductionprograms (other than merely by saving because they use less power). The“virtual power provider” generally sells “megawatts” as previouslydescribed by aggregating demand response capability of many small usersand selling demand response services to the utility. This methodsimilarly discourages consumer participation, because the majority ofthe financial rewards associated with the demand response are notgenerally passed along to the consumer. The companies that aggregatedemand typically charge utilities for the peak reduction, but theconsumer is unable to sell their available “megawatts” directly to autility. This is problematic because this methodology reduces consumerincentives to participate in demand side management, which is anecessary component of modem grid management. And adoption is hamperedby the general lack of willingness on the part of consumers to allowutilities to control significant portions of their electricity usagewith the consumer having little “say” in the matter. And, from theutilities' point of view, the large variations in consumer usagepatterns means that it is much harder for utilities to gage how muchdemand reduction is enough, in advance; compared to large, stable userssuch as large office buildings or industrial facilities, utilities facea complex mix of user patterns that are difficult to predict andvirtually impossible to control. As a result, at the present time almostno demand reduction takes place among consumers and small business usersof the electric grid.

Another problem in the art today is the incorporation of distributedgeneration and storage systems, which are proliferating, into griddemand management systems. In many cases, consumers are unable to domore than to offset their own electric bills with generation units (suchas microturbines powered by wind, or solar panels on a roof, or plug-inelectric hybrid vehicles that could add energy to the grid when needed),because utilities have neither the means nor the motivation to pay themfor the extra electricity they generate. Many states require utilitiesto buy excess power generated; but, without an ability to sell thatgenerated power at a price that represents a more holistic view of itsvalue that includes “embedded benefits” (i.e. at a rate that mayconsider, but is not limited to, the effect on enhancing local powerquality, proximity to loads, type of power generated and the associatedreduction in carbon and other negative externalities—like sulfur dioxideand nitrogen dioxide—and the reduced capital costs resulting from thereduction of required capital investments in infrastructure), mostdistributed power generation remains economically unfeasible, to thedetriment of all parties. With the growing number of markets associatedwith trading negative externalities associated with electrical powergeneration (most prominently including carbon, but also nitrogen dioxideand sulfur dioxide), it is necessary to filly account for the value ofsuch energy sources and storage options, and to ensure that doublecounting of environmental benefits that are related to the generationand distribution of the electricity itself is not conducted. Sulfurdioxide and nitrogen dioxide became regulated in the U.S. under the 1990Clean Air Act Amendments, which established the EPA's Acid Rain Programto implement a cap-and-trade method to reduce harmful emissions from theelectric power industry. Additionally, while storage units may allowusers to avoid peak charges and to even the flow of locally generatedpower (for instance, by storing wind power during high wind conditionsand returning it when the wind conditions are low), it is generally notpossible for users to sell stored power to the grid operator at its truevalue for the same reasons.

An additional challenge associated with integrating distribute energyresources with the grid is the lack of a cost-effective means ofaggregating distributed power generation into a form that can be tradedin a manner similar to the large blocks of power that are bought andsold by more traditional commercial power plants like coal and nuclear.Complex industry rules discourage participation and even consolidatorshave been hesitant to enter the market given the high set up costsassociated with communications, staffing, and industry monitoring. Amechanism is needed to enable equal participation of distributed energygenerators (e.g. solar panels on the roof of a home) and traditionalpower generators in order to encourage the development of theseresources.

An underlying difficulty that contributes to the problems alreadydescribed is that consumers (commercial, industrial, institutional, orresidential participants in energy markets) have no way to differentiatebetween one unit of energy and another in energy distribution systems,such as the electric grid, that are best viewed as “continuous-flowenergy networks”. This type of network can be contrasted with “discrete-or packet-flow energy distribution networks” such as the coaldistribution system. The global oil distribution network is a goodexample of a hybrid, or mixed, energy distribution network that usesboth discrete-flow and continuous-flow techniques at various points inthe network. With continuous-flow energy distribution networks such asthe electric power distribution system (or grid) and the natural gasdistribution system, the units of energy are indistinguishablephysically, one from another, at the point of consumption. That is, aconsumer cannot differentiate one kilowatt of electricity arriving ather home or business from another, and in general has no ability todifferentiate between energy having desirable qualities (to her) such asrenewability, low carbon footprint, derivation from local or at leastdomestic (as opposed to foreign) sources, and so forth. Since thephysical properties of electricity or natural gas are essentially fixedand do not vary based on the source, the only attributes consumers canknow are quantity and price. While in some cases utilities makeavailable about information about the aggregate sources of theirelectricity, and while they may in some cases make a small number of“packages” available to consumers based on differing mixes of sources(for instance, “black, green and in between” menu choices based onpercentage of renewable or low-carbon sources for each option, withprices varying accordingly), it is in general true that consumers haveno information about the particular energy they are using at any giventime, and no ability to make informed choices as energy consumers.

Today's energy distribution networks are “information-poor” and treatenergy as a commodity that is only differentiated by price. What isneeded is an “information-rich” energy distribution network.

It is an object of the present invention to provide an information-richenergy distribution network capable of enabling all energy consumers tofully participate in, and benefit from, market-based programs used bythe utilities that serve them. It is a further object of the presentinvention to provide a means for enabling owners of distributedgeneration and storage systems to make their power available for saleand distribution across the grid. It is a further object of the presentinvention to make the embedded benefits associated with the reduction ofdemand and/or the generation of power—to include, but not limited to,collaborative Greenhouse Gas Programs, carbon credits, sulfur dioxideemissions (SO₂), and nitrogen dioxide emissions (NOx)—from a distributedresource available for sale and trading.

SUMMARY OF THE INVENTION

According to a preferred embodiment of the invention, a system formanaging energy, comprising a processor coupled to a packet data networkand a server software module executing on the processor, is disclosed.According to the invention, the server software module is adapted tosend and receive information over a packet data network from a pluralityof client software modules associated with energy load devices or energygenerating devices associated with one or more end users of energyprovided by an energy distribution network, and to send and receiveinformation from a plurality of software modules associated with energydistribution networks over the packet data network. At least some of theinformation sent from the server software module to the software modulesassociated with energy distribution networks is based at least in parton information received from one or more of the client software modules,and at least some of the information sent to the client software modulesis based at least in part on information received from at least one ofthe software modules associated with energy distribution networks.

According to another embodiment of the invention, a method for managingenergy is disclosed. According to the method, information is receivedvia a packet data network from client software modules associated withenergy load devices or energy generating devices, at least some of whichare also associated with one or more end users of energy provided by anenergy distribution network. Also, information is received via thepacket data network from software modules associated with an energydistribution network. Then, information is sent via the packet datanetwork to at least one of the software modules associated- with anenergy distribution based at least part on the information received fromone or more of the client software modules, and likewise information issent via the packet data network to a plurality of the client softwaremodules based at least in part on the information received from one ormore of the software modules associated with an energy distributionnetwork.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 (PRIOR ART) is a block diagram illustrating common elements ofelectric power distribution systems.

FIG. 2 is a block diagram of simple energy information nodes (or iNodes)according to an embodiment of the invention.

FIG. 3 is a block diagram of a home energy management network accordingto an embodiment of the invention.

FIG. 4 is a block diagram of a home energy network with an integratedsmart meter according to an embodiment of the invention.

FIG. 5 is a block diagram of various means for users to interact withhome energy networks according to the invention.

FIG. 6 is a block diagram of an embodiment of the invention in whichdevice-level iNodes are directly connected to the Internet.

FIG. 7 is a block diagram of an embodiment of the invention in whichhome iNodes are connected to local iNodes such as neighborhood energymanagement systems.

FIG. 8 is a block diagram of a local iNode according to an embodiment ofthe invention.

FIG. 9 is a block diagram of a commercial building energy managementsystem with an iNode according to an embodiment of the invention.

FIG. 10 is a block diagram of a digital energy exchange according to anembodiment of the invention.

FIG. 11 is a block diagram of a digital energy exchange system accordingto an embodiment of the invention.

FIG. 12 is a block diagram of a trading iNode according to an embodimentof the invention.

FIG. 13 is a diagram of a process for allowing consumers to expressenergy usage preferences, and to have those preferences carried out,according to an embodiment of the invention.

DETAILED DESCRIPTION

The inventors provide, in a preferred embodiment of the invention, asystem for managing continuous-flow energy distribution networks that isparticularly adapted for managing electric power demand and distributedgeneration capacity among a large number of consumers, such asresidential, small and large commercial, institutional (that is,hospitals, schools, and the like), and industrial users. The systemrelies on an overlay packet data network comprised of energy informationnodes, or iNodes, which overcomes the previously discussed limitationsBY overlaying a rich set of informational attributes on continuousenergy flows such that consumers can use these information attributesand dimensions to make informed energy choices. A key advantage of theinvention is that while a single physical network carries power from allsources, the available energy at ant given node is priced and allocatedseparately as a finite resource based on data attributes of the system.

Furthermore the new system enables consumer preferences to beimplemented through selection of energy sources by explicitly namedsources, or brands, or by any of a large number of informationattributes or dimensions. The system of the invention enables newconsumer behaviors such as paying more for certain energy source types,or even avoiding purchase (embargoing) of certain energy types orsuppliers (for example, some consumers may choose to undertake thedifficult path to becoming a “no coal electrical household (orbusiness)” by refusing to take any coal-based electricity, no matter thecost (or even the lack of availability of alternatives for someperiods). In addition, information attributes create a large opportunityfor commercial branding, advertising, search and market making, inaddition to passing on regulatory compliance information to consumers.

For the purposes of describing the invention, two related terms are usedherein. An “eNode” is a physical node in a continuous flow energydistribution system at which energy is stored or transformed (in thesense that generation and consumption of electricity are both energytransformations, since energy is never created nor destroyed). Examplesof eNodes include switches and breakers, generators, motors, electricappliances, home power distribution panels, meters, and so forth. Thecontinuous flow electrical distribution network can be thought of as anetwork of “pipes” or “channels” connecting a large number of eNodes;electricity flows through these channels (mostly these are wires ofcourse) and is transformed, stored, controlled, and measured at variouseNodes. While the examples described herein will be electrical networkexamples, the same descriptions could be made by reference to othercontinuous flow energy distribution networks, or the continuous flowportions of mixed energy distribution networks, without any loss ofgenerality; the invention should be understood to have as its scope anycontinuous flow energy distribution systems and the focus on electricityshould be understood as being exemplary and not limiting.

A key element of the invention is the use of an overlay packet datanetwork comprised of “iNodes” and coupled to the continuous flow energydistribution network of eNodes that was just described. In general,iNodes are associated with (or coextensive with) corresponding eNodes,and have interfaces capable of bidirectional data exchange with otheriNodes. For example, where a metering device is placed in a physicalnetwork (this is an example of an eNode), an iNode would be a datadevice adapted to receive readings from the metering device and to passthose readings on, via a packet data network, to other iNodes.Conceptually, the entire physical, continuous flow, energy distributionnetwork may be overlaid by a packet-based data network of iNodes thatcommunicate sensor readings, perform calculations related to the energyflows in the energy network, send control signals to actuating elementsin the physical network (such as a signal to open a breaker, or to starta generator), and communicate information pertaining to the energynetwork to interested users (both human and automated).

Although modularity of iNodes it is not necessary according to theinvention, most iNodes described herein are highly modular in nature sothey can be easily connected peer-to-peer and in trees or hierarchiesand inserted into networks at different levels. Modular design has asadvantages the facilitation of scalability, flexibility, security,robustness, standardization, and suitability for progressive deployment.

The use of a network of iNodes makes it possible to collect detaileddata about usage patterns from large numbers of energy users, includinghow these usage patterns vary during various time periods, includingpeak demand periods and periods when sources of renewable energy (suchas wind or solar) are unavailable or are available in abundance.Additionally, detailed data on how each user reacts (eitherautomatically or otherwise) to management signals sent during peakdemand or other periods, is collected. For example, some users maysignificantly reduce demand when requested, and may do so promptly.Other users, conversely, may not react at all, or may reactsporadically. The same variations in response may occur among operatorsof distributed generation or storage facilities. There are many reasonswhy reactions will vary, and even why reactions may significantlydeviate from demand reductions that were explicitly volunteered by auser. For example, when a peak period arrives, a user who volunteered toparticipate in demand reduction might be on vacation, or out of theirhome for any reason, and so many of the loads that would be targeted mayalready be secured (turned off). Similarly, some user-owned distributedgeneration facilities may be able to react to management signals bychanging the generation profile, while others (for instance, solarsystems) may not be able to change in response to demand managementsignals (because they are dependent on the sun or another uncontrolledfactor).

According to an embodiment of the invention, this usage data is analyzedto create response profiles for each affected user. A response profilereflects an amount of load likely to be actually reduced (or generated)by a user, when requested. The profile may be quite complex, reflectingthe varying predicted behaviors for a user on different days, atdifferent times, during different seasons, and so forth. Responseprofiles can also be generated, according to the invention, on classesof users, large or small, who behave in similar ways; it is notnecessary for each user to have an individual response profile.Furthermore, response profiles can be quite dynamic; for example, aresponse profile may express a conditional behavior such as “if therehas been usage of at least X kwh in the two hours prior to the period ofinterest, then the user is likely at home and the expected response isY; otherwise the expected response is Z”. In the example given, Z wouldlikely (but not necessarily) be less than Y, and would reflect the factthat both fewer loads are likely to be active (because the user is away,as inferred by lack of use in the earlier period) and that no userreaction to any demand reduction request is possible because the user islikely not at home. In other embodiments of the invention, users mayhave home automation systems implemented and could receive notificationvia email, SMS text message or other means while away from home, andthus be enabled to take actions to reduce load when needed; thiscapability would be reflected in the response profile for such users orclasses of users.

In an embodiment of the invention, consumers and small businessesparticipate voluntarily in supply (generation and storage) or demand(consumption) management programs by establishing preferences.Preferences can take many forms. In some cases, users may state thatcertain loads are “off limits” or “critical”, and can never be turnedoff remotely for any load conditions. Other loads may be given one ormore attributes that can used to determine if the load is available inany given situation for remote deactivation. Attributes could includetime of day, length of time since the load was turned on, length of timesince the load was last remotely deactivated, level of criticality ofthe demand reduction effort, price to be paid for shedding the load(“don't take this load offline remotely unless 1 will be paid $1 for thesacrifice”), or even the communication required to confirm (for example,“this load can only be turned off if a message is sent to its automaticcontroller and the automatic controller states that it is safe to turnoff the device”). Another user might express the preference that storedsolar energy will be placed on the grid when the price is at a certainlevel, or when the level of criticality of the peak is sufficientlygreat. It will be appreciated that any number of consumer or smallbusiness preferences are possible for controlling when and whether oneor more loads are made available for remote deactivation. Moreover, thesame considerations that apply for deactivation can also be applied foractivation in the case where generating capacity or storage capacity isavailable. Consumers and small businesses may have, in aggregate,substantial amounts of power in storage or ready to be generated ondemand, if the management system was in place to request it and tomanage it. Again, each user's supply-side resources (generation andstorage capacity) can be made available according to preferencesestablished by a user. Each response profile also reflects thegeographic location of the user or class of users to whom it pertains.This information is important for determining which utility, and whichparticular grid locations (such as substations, tie lines, or regions)will be affected by the activation of the response profile, and to whatextent.

In an embodiment of the invention, a number of response profiles arecombined to create a response package. Because statistical behavior ofusers whose profiles are combined in the response package is known, andbecause a large number of profiles are normally combined into a package,it is possible according to the invention to estimate with good accuracyhow much load reduction (or generation) each response packagerepresents. For example, a response package made up of the collectedresponse profiles of 10,000 consumers might be expected to yield 1.5 MWh(megawatt-hours) of load reduction during a particular 15-minute peakload period. Each time this response package is “invoked” (that is, eachtime a signal is sent to all the users represented by the responsepackage), the actual demand change effected is measured, and used torefine the statistical model for each response profile and for theresponse package as a whole. In this way, according to the invention,the system for energy management continually adjusts to maintain highlyaccurate models of supply and demand changes in response to invocationsof response packages (reductions through load shedding or additionsthrough generation of power or release of power from storage). As withresponse profiles, each response package has a geographic element. Forinstance, it may represent elements (loads and generation/storageelements) spread across a particular utility's area of responsibility,or it may represent elements in a particular urban region.

In a preferred embodiment of the invention, response packages are madeavaiiable for purchase by third parties. Purchasers could be utilitieswho desire to directly manage demand, or they could be aggregators whoresell demand management to utilities at peak period. According to theinvention, a given response package can be sold for any time period atany time in the future (or indeed for the current time period). Thus aresponse package for reducing load in San Francisco by 10 MWh for the15-minute interval starting at noon on Friday, Mar. 31, 2010 could besold at any time before 12:15 on that day. Because the package is sold,according to a preferred embodiment of the invention, on an open market,it is likely that the price would vary over time based on marketparticipants' estimates of the likely demand for power at the criticaltime for this package (that is, at 12:00 on March 31^(st)). Inprinciple, the package can be sold more than once according to theinvention, although in the end only one “owner” is able to actuallyelect to invoke the demand response action represented by the package.It should be noted that actual exercise of the demand response actionrepresented by any given response package is necessary according to theinvention; if load conditions are markedly different from what the finalpurchaser expected, that entity may elect not to incur additional costs(described below) by actually exercising the demand response action.

According to an embodiment of the invention, consumers make theirpreferences concerning their willingness to participate in on-demandenergy management actions (that is, load reductions or provision ofpower from generators or storage systems) known in advance. Sinceconsumers are unlikely to be willing to enter into long-term forwardcontracts for electric power actions that they may find quiteunpalatable when a critical day arrives (for instance, if the weather ismuch warmer than expected, consumers may balk at letting their airconditioners be turned off), it is possible according to the inventionfor consumers to override their preferences at any time. Indeed this isone of the reasons that relying on consumers for demand response is soproblematic, and why utilities seek to have remote control wheneverpossible (although this is rarely possible, and is even illegal in somejurisdictions because of regulatory requirements). In order to provide alevel of control that consumers will want or require, and to provide areasonable energy management capability to utilities, the combination ofa number of consumers' (again, these can also be businesses) responseprofiles into response packages of sufficient size that they will belarge enough to be useful and will have predictable statisticalbehavior, is carried out. According to a preferred embodiment, when autility or other entity actually invokes a response package (forinstance, by actually requesting the demand to be reduced by 10 MWhduring the critical period), all of the end users that make up theresponse package are sent signals directing them to take the appropriateactions which they previously volunteered to take. While some will failor refuse to do so, this has generally already been taken into accountby building the response profiles and the response package to reflectthe statistical patterns that this particular package of users has shownin the past, so according to the invention the actual demand responseseen should closely approximate that specified as the “rating” of theresponse package (in the example above, the rating would be 10 MWh ofdemand reduction in the target time period).

Actual responses that occur when a response package is invoked aremeasured according to an embodiment of the invention. This measurementis used to refine statistical models used for response profiles, asdescribed above. Also, according to an embodiment of the invention, aninvoking entity (an entity which invoked a supply or demand responseaction associated with the response package) may optionally only becharged according to a supply or demand response that actually tookplace. For instance, while 10 MWh was forecasted and requested, if only9.5 MWh was actually achieved, the price paid by an invoking entitywould be reduced. Any reduction could be linear, so that in the examplegiven the entity's actual price is reduced by 5%, or it could be set byany formula agreed in advance by the parties in the marketplace (forinstance, the price difference could be set at 5% reduction for anyshortfall from 0% to 5%, 10% for any shortfall above 5% but less than orequal to 10%, and so forth). It should be appreciated that any priceadjustment schema can be used according to the invention, and thatsimilar adjustments (or no adjustment) could be made if the responseaction exceeded what was requested (typically, one would expect that anyoverage would not be charged to an invoking entity, but this is notrequired according to the invention).

FIG. 1 illustrates many of the elements of continuous-flow electricitydistribution networks as currently known in the art, and is provided togive some context to the embodiments illustrated in subsequent figuresand described below. Electricity is generated in a large number ofutility-owned generating plants 120 as well as many independent powerproducers 122 such as wind and solar farm operators, peaking loadproviders, and the like. The generated electricity is placed onto one ormore regional distribution grids 130. Regional grids are ofteninterconnected by high-voltage interconnects 131 so that electricity canflow relatively freely from where it is generated to where it isconsumed. Power is delivered variously from regional grids viasubstations 121 (although substations 121 are not always used) to largeusers 141, residential and commercial users 140, and others. Gridoperations are controlled from one or more operations centers 110, whichrely on measurements from sensor elements 112 to measure grid operatingparameters (such as voltage, frequency, phase, current, switchpositions, device temperatures, and many others). Changes to gridoperations, such as isolating faults, are carried out under control ofoperations centers 110 using one or more of a large number of controlelements 111. In the art, and illustrated by dashed lines, operationscenters are typically connected by specialized data links to control andsensor elements, and they also routinely share data between them.Several standard protocols, including SCADA and OASIS, are used for datacommunications between electric utilities, and within electric utilitiesto connect with devices. However, in the art there are no meansestablished for data communications between utilities and mostnon-utility entities, with the exception of wholesale markets,independent power producers, and some large industrial and commercialenergy users who have integrated to the utilities' communicationsprotocols. Hence electrical distribution networks today are typified byvery limited data connectivity, both in terms of device coverage (mostelectrical devices are not connected in any way) and in terms ofparticipation by all potentially interested parties (the vast majorityof entities that use electricity are completely disconnected from thegrid in the sense of data, and have no visibility at all into real-timeconditions, nor any ability to make meaningful decisions about theirconsumption of energy.

FIG. 2 illustrates two examples, according to a preferred embodiment ofthe invention, of device-level iNodes. iNodes 210 a and 210 b are eachassociated with a single electrical device 230 a and 230 b. Eachelectrical device is connected to the electricity grid 200 via anelectrical switch 220 that interrupts flow when required, and optionallyvia a current sensor 221 which can measure real or reactive current(current sensors are well-known in the art). These components canoptionally be provided, as shown in FIG. 2, as internal components ofiNodes 210. In an embodiment of the invention, iNode 210 a is a devicewhich can plug in to a standard wall socket and pass electricity throughelectrical switch 220 a and current sensor 221 a to external electricaldevice 230 a, which in some embodiments is plugged into femalereceptacles provided in the packaging of iNode 210 a. It is notnecessary that the iNode be configured for plugging in to wall sockets;in other embodiments iNode 210 a is wired directly in to a facility'selectric system. When hard-wired in to electrical power, iNode 210 a mayeither also have hard-wired electrical connection out to electricaldevice 230 a, or as before it may have standard electrical sockets forthe connection of one or more electrical devices 230 a. iNode 210 b isan example of embodiments in which electrical device 230 b is anintegral part of an iNode; for example iNode 210 b could be a smartappliance that is wired in the normal way to electrical grid 200typically via household or building-level power distribution panels (notshown). iNode 210 b essentially illustrates a smart device that is bothan eNode and an iNode. In some embodiments, iNodes comprise only currentsensor 221 a or electrical switch 220 a, rather than both. For example,an iNode might be designed to measure current through an eNode(electrical device 230) but not to interrupt power to it. For example ifelectrical device 230 a is a generator with independent controlcircuitry, iNode 210 a would be able to measure generated power fromgenerator 230 a and feed that data to data network 201.

According to preferred embodiments, iNodes comprise at least a processor241 such as a standard microprocessor or a customized processor (bothvery common in the art), and a network interface 240, which is connectedto data network 201. Processor 241 is adapted either to receive inputreadings from current sensor 221 or electrical switch 220 (or both), orto send output signals to electrical switch 220, or to do both. Inaddition, in other embodiments iNodes can comprise voltage sensors,temperature sensors, voltage regulators (to receive output fromprocessor 241), or any other sensing or actuating devices known in theart. iNodes are defined by the interoperation of one or more electricalsensors or actuators with a processor 241 a that can communicate withother processors 241 b by passing data through network interface 240 aacross data network 201 to another network interface 240 b associatedwith the other processor 241 b. Various embodiments showing differentarrangements of iNodes to accomplish different purposes will beillustrated and described with reference to FIGS. 3-12; in all of them,and all other embodiments of the invention, it should be understood thatany arbitrary sensor or actuator elements can be used in any giveniNode, but all iNodes have at least a processor 241, a network interface240, and at least one means of sensing or controlling eNodes (electricaldevices 230).

Data communications between iNodes in any given embodiment can beaccomplished using any data communications protocol known in the art (orindeed any novel proprietary protocol); the invention does not rely on,nor require, any particular data communications protocol. Commonprotocols that may be implemented in network interfaces 240 includetransmission control protocol (TCP), universal datagram protocol (UDP),hypertext transfer protocol (HTTP), Java remote procedure calls (RPC),simple object access protocol (SOAP), and the like.

FIG. 3 illustrates a typical home or small business energy managementsystem, according to an embodiment of the invention. Electrical power issent from electricity grid 300 to electrical loads 331, again usuallythrough a power distribution panel and often via a electricity usagemeter (both not shown for simplicity). Electrical loads 331 can includeany electrical devices that consumer electric power, such as heat pumpsand air conditioners, lights or common lighting circuits, hot tubs,computers, ovens, ranges, refrigerators and other kitchen appliances,and any number of other electrical devices common in the art. One ormore electrical loads 331 are coupled with load iNodes 321, for exampleof the type shown in FIG. 2 as iNodes 210. It is not necessary thatevery load 331 in a given home or small business has a coupled iNode321; in many cases only some loads will be monitored or controlled by aniNode. Also, load iNodes 321 may vary among themselves in terms of thedegree of coupling with their respective loads 331. Some may measurecurrent only, others may measure current and voltage, while yet othersmay measure those plus frequency. Some may in fact measure nothing atall, but serve only as controllers. Similarly, some iNodes 321 will haveno ability to control or interrupt electric power to its respectiveelectrical load 331, while others will be able to interrupt load, andyet others will be able to modify the characteristics of the electricpower or control the operation of the electrical load 331. Also, someiNodes 321 may be coupled to a plurality of electrical loads 331, whileothers may (as shown) only couple to one. In some embodiments, one ormore electrical sources 332 are also present in a home or smallbusiness. Some examples of electrical sources common in the art includesolar panels or arrays, wind turbines, or small internal combustiongenerators. Electrical sources or generators feed power into the homepower system and, if it generates more electricity than is used in thehome, they can actually cause electricity to flow back to electricitygrid 300. Source iNode 322 is an iNode similar to those iNodes 210described above, and is adapted to sense the power being generated byelectrical source 332. In some embodiments source iNode 322 is alsoadapted to control, particularly by starting and stopping butpotentially also by regulating output, electrical source 332. Thevarious iNodes (321 and 322) are connected via local network 302 togateway iNode 310. Local network 302 is commonly a simple home datanetwork such as is provided through use of a wireless router connectedto or embedded in a broadband modem (such as a cable or DSL modem). Inother cases, local network 302 is a small business LAN. In a preferredembodiment, local network 302 is a wireless communications networkformed using a specialized protocol such as Zigbee™ that is designed forlow-power wireless data communications. Such networks are useful becauseit allows load iNodes 321 and source iNodes 322 to be equipped withinexpensive and low-power wireless communications capability, andtherefore greatly assists in facilitating easy installation of iNodessince in most homes and small buildings any wired data network isusually separate from electrical power wiring networks. Low power isimportant in these wireless applications because it allows low-costtransmitters that have long battery life. In other embodiments, localnetwork 302 is of a data-over-power-lines design, several of which areknown in the art (for example, Lonworks™). These are less common andoften more expensive than wireless networks, but they have the advantageof requiring only one wiring system and of avoiding some of the problemswith wireless coverage that are common in buildings (and which sometimesrequire the installation of a number of wireless repeaters that receiveand retransmit wireless signals to aid in their propagation throughoutbuildings). In other embodiments, local network 302 may be identicalwith external data network 301, as when each source iNode 322 and loadiNode 321 is directly connected either to the Internet or to aneighborhood or building-wide (as where the group of iNodes shown inFIG. 3 belongs to a tenant in a commercial building or an apartmentbuilding) wireless data network. Gateway iNode 310 is so called becauseit acts as a gateway between local iNodes such as source iNode 322 andload iNodes 321. In some cases it also acts as a network gateway as isillustrated in FIG. 3, acting to bridge the local network 302 andexternal data network 301 such as the Internet (in cases where localiNodes are directly connected to external data network 301, this networkgateway function would not exist, and gateway iNode 310 is optionaldepending on the information flow desired according to each embodiment).

Gateway iNode 310, in an embodiment of the invention, comprises aprocessor 311 and a local network interface 313, as well as a networkinterface 312 for coupling to external data network 301. Inconfiguration where local iNodes connect directly to external datanetwork 301, gateway iNode may only have one network interface 312.Gateway iNodes 310 at a minimum have an operating system operating on,and a storage medium (not shown) coupled to, processor 311; in allfigures showing processors in iNodes, it is intended to be understoodthat some form of local storage and an operating system are understoodto be included in the processor element; these are not shown to avoidundue complexity but are considered to be inherent to the functioning ofany processor.

In various embodiments of the invention, software 315 executes onprocessor 311 to carry out the key logical functions of gateway iNode310 as part of an overlay packet data network overlaid across some setof elements (331 and 332 in the embodiment illustrated in FIG. 3) of theelectricity distribution network of electricity grid 300 and itsconnected elements (that is, an electricity distribution network asreferred to herein refers to networks comprising one or more of theelements of FIG. 1 coupled by one or more electricity grids 130 (or300). For example, in some embodiments software 315 receives (via localnetwork interface 313) updates from local load iNodes 321 and sourceiNodes 322 concerning their state; example of such updates includecurrent, voltage, frequency, true and reactive power readings, as wellas settings of control elements such as switches. Updates may be sentfrom local iNodes on a regular basis, for example every 15 seconds, orwhen a value changes by some specified minimum amount, for example whenchanged by more than 10% from average of last five readings, or whenpolled by software 315. Software 315 in some embodiments sends controlsignals to control elements associated with local iNodes. For example,in response to a signal received from data network 301, software 315could automatically shed some or most electrical loads under its control(that is, controlled by actuators or control elements in turn controlledby one of its child load iNodes 321 a-c) by sending signals to theappropriate load iNodes instructing them to interrupt current to one ormore of their controlled loads. Similarly, software 315 could, inresponse to a signal from data network 301 or at a scheduled time(determined from a schedule stored in its associated data storage), senda signal to source iNode 322 instructing it to start or to stopgenerating electricity, or to change the amount being produced. In theseembodiments, gateway iNode 310 becomes a key element of a system thatenables dispatched electricity supply or demand management, as it isadapted to be connected via data network 301 to one or more dispatchers,to process received signals in order to determine precisely what is tobe done locally, and to carry out the requested actions by sendingcontrol signals to one or more child iNodes associated with it(generally in the same household, or tenant); it is also adapted forbeing a data collection element of a larger system by managing thecollection of operating data from all of its child iNodes, processingthat data as by aggregating it, and passing the data “upstream” via datanetwork 301 to other system elements that may for example aggregate datafrom a large number of gateways 315.

In another embodiment of the invention, and referring to FIG. 4, anenergy management network for a home or small business similar to thatof FIG. 3 is illustrated, with the addition of smart meter 410.Generally, all users of electricity who draw at least some of theirpower from electric grid 400 are provided (by the utility) with a meterfor measuring the amount of energy used at a particular location. In thepast, and still today in a large proportion of locations, meters areread by human meter readers on a monthly or semi-monthly basis. Thispresents obvious cost implications for utilities, which must pay thosereaders, and has led to many innovative approaches (including havingconsumers read their own meters with periodic unannounced audits by anexternal, utility-pair meter reader). Recently, a wave of introductionsof automated meter reading (AMR) systems has been seen. These havequickly been succeeded by a more useful innovation, the smart meter 410,and its accompanying advanced metering infrastructure (AMI). While oneof the goals of utilities in automating meter reading has been to reduceand eventually eliminate the need for human meter readers, anotherpotentially much more lucrative motivation has been the possibility ofobtaining meter readings on a frequent basis instead of only once permonth. If meters are read, for example, every fifteen minutes, thenutilities are able to measure how much energy is used by each rate payer(consumer, whether commercial, residential, institutional, orindustrial) during peak usage periods. This is an essential preconditionto the very desirable (from the utilities' point of view) shift tovariable pricing schemes. In a variable pricing scheme, the price of aunit of electricity (typically measured in kilowatt-hours, or kwh) isvaried based on demand. During peak periods, the cost of generatingelectricity is commonly much higher, as expensive (and oftenindependently operated by for-profit IPPs) peaking power plants must beutilized for a portion of the overall load; by contrast, duringlow-demand period most power is generated by very low-cost sources suchas large coal plants and hydroelectric plants. Smart meters make allthis possible, partly by being connected to the operations centers ofutilities by a data network associated with the grid (shown together asgrid and data network 400). In most cases, smart meters are designed toenable integration of home automation systems via local network 302. Forexample, small businesses or homes with wireless automation systems formanaging lighting, HVAC (heating, ventilation, and air conditioning)systems, and the like are able to integrate these systems with smartmeters. Often this is done to enable consumers to participate inoptional (or even mandatory) demand response programs in which utilitiesare allowed to turn off, automatically, certain loads to reduce demandduring peak periods (typically providing a discount to consumers willingto enter into such arrangements as an inducement to do so).

In an embodiment of the invention, smart meter 410 is integrated with ahome energy management network according to the invention through smartmeter iNode 420. Smart meter iNodes act in effect as a gateway to thesmart meter and to the utility beyond. As such, it will typically havean internal architecture similar to that of gateway iNode 315, althoughthis is not necessary as in some cases smart meter 410 can be integrateddirectly with local network 302, as when a Zigbee™-compliant smart meteris used with a Zigbee™ home energy management network. In someembodiments, smart meter iNode acts as a load iNode, passing meterreadings to gateway iNode 315. Gateway iNode 315 is able, with thebenefit of meter-level usage data (which provides data about total usagein the home or business), to calculate (in software 315 operating onprocessor 311) the amount of load that is not monitored or controlled byload iNodes 321 by subtracting from the total the total load that ismonitored by load iNodes 321. Analogously, if source iNode 322 ismeasuring a non-zero amount of generated power, the total unmonitoredload can be calculated by subtracting from the smart meter reading thetotal of load iNode readings and adding in all source iNode readings.This capability is useful because it allows unmonitored loads to beaccounted for, and in some cases users could be prompted to secure(stop) unmonitored loads in a demand reduction scenario, in effectadding a manual load reduction capability that can be mediated bygateway iNode 315. There are any number of uses to which a systemcomprising an integrated smart meter 410, gateway iNode 310, and avariety of load and source iNodes 321 and 322 can be put, according tovarious embodiments of the invention. For example, if a utility sends ademand response signal directing the user corresponding to smart meter410 to reduce a certain amount of load immediately, this reduction canbe managed by gateway iNode 310. Gateway iNode 310 could carry out therequested demand reduction in a variety of ways. It could direct one ormore load iNodes 331 to interrupt their power (that is, to turn offtheir loads), to provide some of the required reduction. It could directsource iNode 322 to actuate its control of electrical source 332 inorder to start the generator or to increase the amount of electricity itgenerates. It could even coordinate, over data network 301, with othergateway iNodes to request that they shed some of the load cooperatively(of course, issues of verifiability will arise in such a scenario, andparticularly of verifiability of non-duplication: the same loadreduction should not be counted twice).

FIG. 5 illustrates several (although by no means all) of the ways inwhich human users can interact with home or small business energymanagement networks according to embodiments of the invention. In apreferred embodiment of the invention, a user accesses information,establishes preferences, and takes actions concerning energy managementusing home computer 510. Home computer 510 may be a desktop personalcomputer, a laptop, a “netbook” (a small portable computer with wirelessdata networking built in and limited capabilities), or any other generalpurpose computer. Home computer 510 may be connected separately to localnetwork 302 and to external data network 301 (for instance, theInternet), or it may be connected to both through a broadband router, asis common in the art (that is, with this common configuration, homecomputer 510 can access other computing devices including possiblyvarious iNodes via local network 302 and remote data sources viaexternal data network 301 using a single network interface card that isconnected to a broadband router. In some embodiments, gateway iNode 310may connect to home computer 510 only via the Internet (often throughthe use of a remote website operated by another entity for the purposeof allowing homeowners and small business operators to manage theirenergy management networks. This approach would be common where, forexample, local network 302 is a specialized wireless network based on astandard such as 802.15 or Zigbee™; desktop computers are typically notequipped to interface with such networks. In other embodiments, usersmay interact with their home energy management networks from remotelocations using laptop or handheld computers 512 and communicating overexternal data network 301 (for example, the Internet); in otherembodiments, users may interact using mobile devices connected overcommunications network 500 (typically a wireless network with datacapabilities, as are common in the art today). Wireless device 511 couldbe a laptop computer equipped with a cellular modem (or wirelessbroadband access card), a mobile phone (especially, but not necessarily,a smart phone such as an iPhone™ from Apple, a Blackberry phone, or aphone based on Google's Android operating system), or a handheldcomputer equipped with wireless connectivity. Interaction using any ofthe devices shown in FIG. 5, or any comparable devices known in the artcapable of acting as communicating data processing devices, may beaccomplished using web browsers (when a third party service or a gatewayiNode 310 provides web-based access services), or a dedicated softwareapplication that is adapted to interface using appropriate protocolswith gateway iNode 310 or a third party service that mediates access togateway iNode 310.

According to an embodiment of the invention, and illustrated in FIG. 6,iNodes are connected directly to external data network 301 rather thanbeing connected through gateway iNode 610. Accordingly, gateway iNode610 is only required in this embodiment to have one network gateway(although obviously a gateway iNode 310 with two network interfacescould be used, with one of the interfaces merely remaining idle). Also,although not shown separately, in another embodiment a mixed approach istaken: some iNodes connect to the external network 301 via a gatewayiNode 310 with two network interfaces, while others connect directly toexternal data network 301 as shown in FIG. 6. While load iNodes 321,smart meter iNode 420, and source iNodes 322 could be hard-wired toconnect only to gateway iNode 610 over external data network 301, insome embodiments local iNodes would connect to a service provider 600over external data network 301, and identify themselves, for instance byeach iNodes' providing a unique serial number to service provider whenfirst connecting. The system disclosed in FIG. 6, like all embodimentsof the invention described herein, is not limited to use in a particulartype of venue such as homes or small businesses; the use of homes andsmall businesses is exemplary and not limiting. For example, load iNodes321 could be a large number of dispersed electrical loads possibly underthe economic control of a large number of entities. For instance, laptopcharging stations in public places could be deployed by the owners oroperators of the various public places, and made accessible to thirdparty users such as travelers or coffee shop visitors via serviceprovider 600. In some embodiments, patrons wishing to recharge laptopswould connect via data network 301 to service provider 600 and make asmall payment (or a donation to a charity), and service provider 600would then send a signal to enable a corresponding electrical device 331(i.e., outlet) allowing the patron to recharge. In another embodiment,such patrons could identify themselves and their utility provider andaccount number, and any electricity usage in (for example) electricalload 331 a would be measured by iNode 321 a and passed to serviceprovider 600, who could then pass the data on to an appropriate utilityprovider for billing (possibly collecting a percentage fee which maythen possibly be shared with the owner or manager of the location atwhich the charging patron is located). This example should make clearthat there are many economic scenarios enabled, envisioned andencompassed by the invention, and it is reiterated that these examplesshould not be considered as limiting the scope of the invention.

In a preferred embodiment of the invention, illustrated in FIG. 7, ahierarchical arrangement of iNodes is illustrated. A plurality ofpremise iNodes 710 is connected to one or more local iNodes 720 via datanetwork 700 a. Optionally, a plurality of local iNodes 720 is connectedto one or more regional iNodes 730 via data network 700 b. Manypermutations and combinations are possible. Premise iNodes commonly, inembodiments of the invention, have child iNodes corresponding toparticular electrical loads, sources, and so forth. As an example,premise iNode 710 a may be a gateway iNode of a home energy managementnetwork of a type such as those illustrated in FIGS. 3-6. It could be agateway iNode for a tenant in a commercial office building. It could bea gateway iNode for a single building in a college campus or a highschool. It could be an isolated source iNode for a diesel generatornormally used as an emergency power supply for a large retailestablishment but configured to start on demand under control of a localutility during extreme demand periods. Similarly, local iNodes 720 couldbe of many types and could have many purposes, without departing fromthe scope of the invention. For example, a local iNode 720 b could be aneighborhood cooperative energy management system's central node,receiving inputs from a utility (regional iNode 730 in this example)concerning desired demand levels, and from a plurality of home gatewayiNodes 710. The neighborhood energy management system could coordinateamong the participating neighborhood residents' premise iNodes 710 to,for example, coordinate the starting of heat pumps and air conditioningcompressors during periods of high heat load (which are usually alsoperiods of high electricity demand), in order to ensure that no twocompressors or heat pumps start within a specified time of each other(heat pumps, compressors, and the like have high starting currents, andwhen many attempt to turn on nearly simultaneously, large load spikescan be experienced that can destabilize grid operations). Neighborhoodmanagement systems could also coordinate to ensure that the overallenergy usage of a particular neighborhood does not exceed some specifiedlimit (coordination is carried out by sending signals to premise iNodes710 and in effect operating the premise iNodes and the local iNode as adistributed software system for optimizing energy usage profiles of theneighborhood as a whole). In another embodiment, one or more of premiseiNodes 710 is a distributed storage system operated as a common asset ofa local iNode's and its child iNodes; for instance, a neighborhood mayinvest in distributed battery storage systems, and possibly also inseveral generating devices, and these may be operated under control oflocal iNode 720 b to manage overall load as viewed by regional iNode730. Additionally, in such an arrangement, when prices are high due tohigh demand, local iNode 720 b could direct generators and storagesystems to deliver power to the members of the local community to avoidtheir having to pay the higher prices; storage could be “topped off”later when prices drop back to their normal, lower levels. This type ofpower management would actually be a boon to utilities as well as totheir customers, as it is often quite expensive for them to deliverpower during peak periods, and many of the ratepayers remain on fixed,regulated tariffs that are much lower than peak prices. In someembodiments, data networks 700 a and 700 b are identical (often theInternet serves both functions, but other single networks could also doso). It should be appreciated from these examples that the overlaypacket data network approach of the present invention allows a widerange of deployment architectures, of which the examples given are asubset. For instance, there could be many layers of hierarchy, and agiven premise iNode 710 could be logically connected to, and communicatewith, and possibly even be controlled by, more than one local iNode 720,and a local iNode 720 could be connected to, communicate with, andpossibly even be controlled by, more than one regional iNode 730. Or, inanother embodiment, several distinct layers beyond the three layersshown in FIG. 7 are possible. And, in yet other embodiments, a giveniNode may participate as a local iNode 720 with respect to certainapplications or subnets, as a premise iNode 710 in other applications orsubnets; that is, a given iNode could function at different hierarchicallevels for different purposes. Moreover, in highly interconnectedscenarios, it may be more useful to think of iNodes as being arranged ina web. And, since iNodes are generally associated with correspondingeNodes or physical elements of the underlying continuous flow energydistribution network (on top of which the overlay packet data network isoverlaid), the architecture of large scale distribution of iNodesaccording to some embodiments of the present invention will often cometo resemble the hub-and-spoke-with-hierarchical-subnets arrangement oftypical large-scale electrical distribution systems.

FIG. 8 shows an exemplary architecture, according to an embodiment ofthe invention, for intermediate iNodes 800 (intermediate in that theyhave both child iNodes 803 and parent iNodes 802, as for example thelocal iNodes 720 in FIG. 7). Like gateway iNodes 315, intermediate iNode800 is equipped with one or more communications interfaces 810,depending on whether it needs to connect with more than one network. Insome architectures, intermediate iNode 800 is connected to parent iNode802 and child iNode 803 by the same data network 700. As with alliNodes, intermediate iNode 800 also comprises a processor 830 executingsoftware 835. In some embodiments, intermediate iNode 800 also comprisesa standalone local data store 820, above and beyond such basic storageas is generally associated with processor 830, and which is in manycases a relational database, but need not be. In many embodiments, sinceintermediate iNode 800 may be managing loads and sources (and data) froma large number of child iNodes 803, the functions of local data store820, communications interfaces 810, and processor 830 may execute onphysically separate machines connected by an internal data bus or localarea network (LAN) 840. In some embodiments, local data store 820 isused to store configuration data for child iNodes 803 and intermediateiNode 800, such that, on startup, intermediate iNode 800 readsappropriate configuration data from local data store 820 and setsinternal operating parameters accordingly. Additionally, intermediateiNode 800 may gather network addresses of child iNodes 803 and parentiNodes 802 with which it is associated on startup, and in someembodiments, upon gathering these address locations, intermediate iNode800 initiates data communications with one or more of the child iNodes803 and parent iNodes 802 whose addresses were obtained. Local datastore 820 may also store transactional data concerning transactions suchas demand response requests received from parent iNodes 802, demandresponse requests sent to child iNodes 803, or in another embodiment theidentities of iNodes that bought generated power from a child sourceiNode 803. Since large numbers of intermediate iNodes of considerablecomputational power may be deployed in arbitrary network topologiesincluding structures that can be described mathematically ashighly-connected graphs, an overlay packet data network consisting ofmany low-level iNodes 803 associated with physical eNodes or energyresources and a rich set of intermediate and high-level iNodes 800, canbe expected to be highly scalable, robust against incidental ormaliciously-induced failures of any set of devices, and capable ofcomputations of considerable complexity, such as the optimal routing ofelectricity throughout a nation-sized grid with many separateparticipating entities.

FIG. 9 illustrates another embodiment of the invention according towhich a commercial building automation and energy management system 900is integrated via an intermediate iNode 800. Many large commercial,institutional and industrial facilities already have quite sophisticatedbuilding automation and energy management systems 900 in the art.Commonly, these systems monitor, measure, and control HVAC systems 922,electrical storage devices 923 such as large-scale batteries, electricalsources 921 such as solar arrays or emergency generators, and of coursemyriad electrical loads 920. In many cases, building automation andenergy management systems communicate internally, and make themselvesaccessible to external systems, by communications interfaces 910 usingone of several standard data exchange protocols such as BACnet. Thereare several such protocols, including Lonworks and proprietaryinterfaces for particular control equipment manufacturers. In one sense,one may think of these large-scale systems as very large, complexelectrical devices or eNodes 230, which have attributes common toelectrical loads, sources and storage systems. Accordingly, under apreferred embodiment of the invention, an intermediate iNode 800 isclosely coupled to a building energy management system 900 throughcommunications between BACnet interface 910 and communications interface810 a, which is adapted to be able to pass BACnet messages to and fromBACnet interface 910. Of course, Lonworks or other proprietary or opendata exchange protocols used by building automation and energymanagement systems 900 can also be used instead of BACnet withoutdeparting from the scope of the invention.

FIG. 10 illustrates a digital exchange 1000 according to an embodimentof the invention. A communications interface 1032 is adapted tocommunicate with a plurality of regional iNodes 1030, local iNodes 1031,home iNodes 1032, and trader iNodes 1033. Communications interface 1032is adapted to provide one or more interface means for connection toremote iNodes. Interface means may support various standards such asHTTP, SOAP, RPC, XML, SCADA, VXML, and the like, or may be implementedin a proprietary way; the scope of the invention should not be taken aslimited to any particular means of communication between the digitalexchange 1000 and end users and their energy resources. Digital exchange1000 may be implemented on a single server or other computing device, orits functions may be dispersed among several servers or computingdevices as desired. The various modules of the digital exchange shown inFIG. 10 communicate with each other via a network 1010, which can be alocal area network (LAN), a wide area network (WAN), the Internet, orany other network capable of providing for communication between thevarious elements of a digital exchange 1000.

A configuration database 1022 stores information pertaining to theconfiguration of the components of a digital exchange 1000, as well asinformation pertaining to users who have registered with the digitalexchange 1000. When new users connect with a digital exchange viacommunications interface 1032 from a user interface via a remote iNode(1030, 1031, 1032, or 1033), they are guided through a registrationprocess. Details of this process will vary in accordance with theinvention, but will typically include at least the collection ofidentifying information concerning the user and information to enablethe communications interface 1032 to connect to a remote iNodeassociated with the user, as appropriate. According to an embodiment ofthe invention, when a user provides information enabling acommunications interface 1032 to find and connect to an associatedremote iNode, the communications interface 1032 queries the remote iNodeto obtain a list of devices or energy resources monitored andaddressable by remote iNode. For instance, a home iNode 1032 a mayreturn a list of several loads and one or more generators or storagedevices. Optionally, a user may view the list of associated devices orenergy resources and provide detailed information about one or more ofthe devices or energy resources. For example, a user might start with alist of monitored outlets and appliances that was obtained bycommunications interface 1032 from home iNode 1032 a, and manuallyprovide the information that outlet #7 has a Dell Inspiron computerconnected to it, outlet #8 has a 17-inch monitor connected to it,appliance #1 is a Kenmore washer of a specific model, and so forth. Thelist of “acquired” devices or energy resources, and all associatedamplifying information concerning those devices or energy resources, arestored in configuration database 1022. According to an embodiment of theinvention, configuration database 1022 is also populated with a set ofdata about the standard energy usage profiles of known brands and modelsof electric devices. For example, information may be stored inconfiguration database 1022 concerning the power consumption of variousmodels of Kenmore washers and driers, as well as additional detailedinformation such as the various duty cycles and their associated powerconsumption profiles (the consumption of power by a washer, forinstance, will vary dramatically at different stages of its various dutycycles). Information concerning precautions to be observed whenconsidering deactivating particular devices is also optionally stored inconfiguration database 1022; for instance, it may be unsafe for a washerto turn it off during a spin cycle, whereas it might be perfectly safeto turn it off during a fill cycle.

According to a preferred embodiment of the invention, user preferencesare stored in configuration database 1022. While interacting withdigital exchange 1000, users are given options to express preferencesfor how their energy resources may (or may not) be used by a digitalexchange 1000 to build response profiles and response packages or toexecute energy management actions that involve the user's energyresources. As discussed above, preferences can be quite wide-rangingaccording to the invention, and may include mandatory preferences(preferences that a digital exchange is not allowed to violate, such as“never turn off my television on outlet #14”), or optional preferenceswith conditions (for example, “if the price is more than X degrees, andmy hot water temperature is at least Y, and it is between 8:00 am and4:00 pm local time, you can turn off my hot water heater for as long asneeded or until the temperature drops to Z degrees”), or highlypermissive preferences (“you can do whatever you want to this load,whenever you want”).

According to a preferred embodiment of the invention, events are storedin event database 1020. According to the invention, a very wide range ofevents may be stored in event database 1020. For example, each packet ofdata concerning the state of a device or energy resource can beconsidered an event and stored in event database 1020. To illustrate,consider a washing machine that is monitored and controlled by a homeiNode 1032 b in the home of a user of a digital exchange 1000. When thewashing machine turns on, an event is generated to record that thedevice activated at a specific time. If the home iNode 1032 b isconfigured to pass frequent power readings for the device, then a seriesof events of the form “device N was consuming X kilowatts at time T” ispassed by home iNode 1032 b via communications interface 1032 and storedin event database 1020. Similarly, if a response package is activated,and event is generated; if a particular response action is requested, anevent is generated, and if the requested action is taken, another eventis generated; all of these exemplary events are stored in event database1020. It is desirable, according to the invention, to capture events atas granular a level as is possible for any given configuration (forexample, as in the case of home iNode 1032 b described above, it mayonly be possible to have information at the level of detail of a home,whereas in the case of another home iNode 1032 a discussed above,device-level granularity is possible). According to the invention,configuration changes may also constitute events and be stored in eventdatabase 1020, enabling an audit trail to be maintained (that is,configuration database 1022 stores the current configuration but eventdatabase 1020 will have a complete record of changes to configurationdatabase 1022). Extraneous events, which are events not directlyrecorded by remote iNodes, or other sources within the digital exchangeinfrastructure, may be entered manually or automatically into the eventdatabase 1020. For instance, if a third party provides weather forecastinformation or actual weather information (for example, “it is snowingin Wichita at time 1:00 pm”), this information can be stored in eventdatabase 1020. This is useful according to the invention because it maybe possible to correlate changes in aggregate load across many connectedusers (connected to the communications interface 1320) with weatherphenomena in a very detailed way.

According to a preferred embodiment of the invention, transactiondatabase 1021 stores information pertaining to partial, pending,completed, and closed transactions. According to the invention, partialtransactions may include transactions to which only one party iscommitted at a given point in time; for instance, an offer to sell theright to invoke a particular response package at a particular time inthe future, or a request to obtain a specified level of demand reductionat a specified time in the future, when neither the offer nor therequest has been taken up by a second party. Pending transactionsaccording to the invention include situations where two parties arecommitted to a transaction but the underlying energy actions have notyet been consummated; for instance, if a utility has purchased therights to invoke a response package at a specified time but either thattime has not yet arrived or, if it has arrived, the utility has chosento not execute the response package yet. Completed transactions aretransactions for which the underlying energy resource actions have beentaken. Closed transactions are transactions for which all settlementactions, such as verifying actual energy response actions taken, byuser, allocating funds among various users who participated, andsatisfying all financial aspects of the transaction for all partiesinvolved, have been completed.

It should be appreciated by those practiced in the art that the variousdatabases described herein are for illustrative purposes only. Thefunctions of all of them can be included in a single database system, orthe functions could be distributed over a larger number of databasesystems than outlined herein, without departing from the spirit and thescope of the invention. For example, a configuration database 1022 couldcontain only configuration information pertaining to physical thingssuch as locations of remote iNodes, and consumer preference informationcould be stored in a separate preferences database, without departingfrom the scope of the invention. What is relevant to the invention isthe set of information stored and the uses to which it is put, ratherthan precisely how it is stored; the field of database management isvery advanced and those having practice in that art will appreciate thatthere are many considerations having nothing to do with the instantinvention that may dictate one or another particular architecturalapproach to database storage.

According to an embodiment of the invention, statistics server 1030calculates a plurality of statistics based on data take from or derivedfrom one or more of a configuration database 1022, a transactiondatabase 1021, and an event database 1020. Statistics can be calculatedon request from clients of the statistics server 1030 such as a rulesengine 1031 or remote iNodes provided via communications interface 1032.Statistics can also be calculated according to a prearranged schedulewhich may be stored in a configuration database 1022; alternativelystatistics may be calculated periodically by statistics server 1030 andpushed to clients or applications which may then choose to use thepassed statistics or not. According to an embodiment of the invention,statistics server 1030 is used to characterize an expected responseprofile of a plurality of end users of a digital exchange 1000, whichresponse profile may be for a particular period of time or for anyperiod of time; optionally time-specific and time-independent responseprofiles for a plurality of end users may both be calculated. Accordingto another embodiment of the invention, statistics server 1030 is usedto characterize expected response from a response package built up froma plurality of end user response profiles, which expected response maybe for a particular period of time or for any period of time; optionallytime-specific and time-independent response forecasts for a plurality ofresponse packages may both be calculated. Statistics can be stored in aseparate database such as an event database 1020, or they may bedelivered in real time to a requesting client or application such as arules engine 1031.

According to various embodiments of the invention, statistics server1030 calculates statistics based on a wide variety of available inputdata. For example, statistics server 1030 can calculate the expectedload reduction to be delivered by a single end user or a collection ofend users on receipt of a request for a reduction in load. This may becalculated based on any available data from event database 1020,transaction database 1021, configuration database 1022, or any otherdata source accessible to statistics server 1030 (for instance, weatherdata passed directly in to statistics server from a third party viacommunications interface 1320). Data elements which may be used tocalculate response profiles may include, but are not limited to, pasthistory of responses to similar response requests at the same ordifferent times and on the same or different days. Response profiles canbe calculated based on a type of load to be reduced; for example, if auser has volunteered to make several resistive loads such as waterheaters and resistive space heaters available for reduction on demand,expected response may be calculated by estimating the probability thatsaid loads are actually active at the time of a request, based onprevious history of the activation times for said loads. Alternatively,said resistive loads might always be on, yet an end user mightoccasionally override response actions locally, and statistics server1030 may estimate likely load reduction by estimating the probabilitythat an end user will override a demand reduction signal based onprevious override history. In both of these examples, and indeed in anystatistical calculation made by statistics server 1030, previous historydata can be for the user concerning whom a statistics is beingcalculated, or it can optionally be historical data from a plurality ofusers who are judged by statistics server 1030 to have similarcharacteristics. This allows, for instance, a new user to beincorporated readily into the system and methods of the invention byallowing historical data for already-active users with similarcharacteristics to be used to estimate the expected behaviors of saidnew user. In an embodiment of the invention, demand management may beachieved by altering duty cycles of appropriate loads rather than merelyturning them off, for example, setpoints of an advanced thermostat couldbe adjusted by one or more degrees in order to reduce the aggregate HVACload controlled by the thermostat, or a hot water heater could beallowed to stay offline until water temperature drops to some predefinedtemperature, at which point the heater would turn on. In these cases,the preferences are stored in a configuration database 1022, andstatistics server 1030 calculates expected response by, for example,deriving a response function, expressed as a function of time (wheretime can be defined in various ways, such as the time since the lastduty cycle started, the time since a critical parameter was lastreached, or the time from the response request's transmission to thedevice; this list is not exhaustive and should not be taken as limitingthe scope of the invention), which characterizes the typical responsefor the device. Then, a calculation of the likely response can be madeusing this function and included in a response profile. Note also thatwhenever information about a device type, such as a particular type ormodel of washer, dryer, thermostat, or any other device, is contained ina configuration database, information from either the manufacturer of adevice or an aggregated history from many such devices used by variousparticipants in digital exchange 1000, can be used in lieu of actualusage information from any particular user if desired. In this way,response profiles can be built up with high accuracy for even very newusers (or for users who do not have equipment that enables current orpower measurements per device, as upon listing various devices aresponse profile can be built using typical response profiles for eachdevice the user lists).

In another embodiment of the invention, expected response profiles canbe based at least in part on information that is either real time innature or nearly so. For example, when information about current statusof equipment (on or off, and potentially at which point in a duty cycle)can be gathered, it can be used to modify a response profile by takinginto account the fact that loads which are already off cannot be turnedoff to save power. Similarly, scheduled loads, when known to statisticsserver 1030 (by being stored in configuration database 1022), can beleveraged by taking into account the fact that a given load is scheduledto turn on in a period of interest, and overriding the schedule to keepit off, thus achieving a predictable load reduction for the period ofinterest.

In another embodiment of the invention, users can be assigned an “energyrisk rating” analogous to a credit rating. Statistics server 1030calculates energy risk ratings by taking into account past user history,particularly concerning the degree to which a user honors hiscommitments. For example, if a user volunteers (by establishingpreferences that are stored in configuration database 1022) to allow 3kilowatts of load to be controlled by digital exchange 1000 duringperiods of demand response (or by volunteering to provide generatedpower of 3 kilowatts from a home wind turbine), and then fails toactually deliver according to what was volunteered (either becausedevices were off and therefore not available for load shedding, or windwas not available, or any other reason), then statistics server 1030decrements the energy risk rating for said user. As with credit scores,time can be a key parameter in adjusting energy risk ratings; after aseries of failed commitments, it takes some time before the energy riskrating will rise back up following a change to actually honoringcommitments.

It should be appreciated that the examples of statistical datageneration provided heretofore are exemplary in nature and do not limitthe scope of the invention. Essentially any statistics that can becalculated based on data available about users, their loads andavailable energy resources, their behaviors (for instance, one might beable to infer that a user is at home based on dynamic behavior of powerusage, and use this to predict how responses might differ from those ofa user away from home; in fact, preferences can be stated according toaway or at home profiles, which can be inferred or directly declared asis done with home security systems when a user clicks “Away” to tell thesystem he is leaving the house), the consistency of their responses,their demographics, and so forth.

According to a preferred embodiment of the invention, rules engine 1031or an equivalent software module capable (equivalent in the sense thatit meets the functional description provided herein, which is often doneusing a standards-based rules engine, but need not be so limited)receives events or notifications from one or more of the othercomponents of the invention and executes any rules linked to said eventsor notifications. Events could be received from a third party viacommunications interface 1032 (as when a user elects to invoke aresponse package that he has purchased through digital exchange 1000),or from statistics server 1030 (as when a statistic exceeds someconfigured threshold), or from one of the databases (as when a dataelement is added or changed). Events can also occur, and fire rules,based on calendars; for instance, a daily event might fire which causesa new set of response packages, for times during the day that is oneweek or one month in the future, to be created and stored inconfiguration database 1022 (and made available for purchase on digitalexchange 1000 via communications interface 1320). When an event isreceived, an event handler in rules engine 1031 evaluates whether anyrules are configured to be fired when an event of the type receivedoccurs. If so, rules are executed in an order stipulated, as is commonlydone with rules engines. Rules can generally invoke other rules, so anevent's firing may cause a cascade of rules to “fire” or execute; ruleinvocation and execution continues until no further rules are remainingto be fired. Rules are stored alternatively either in the rules engine1031 itself, or in configuration database 1022. In an embodiment of theinvention, rules are established for the management of responsepackages, so that when a user changes or adds configuration datarelating to loads or energy resources that can be controlled by digitalexchange 1000, a rule is fired which causes the user's response profileto be recalculated and the revised response profile to be stored inconfiguration database 1022. Typically, whenever a response profile isadded or changed, a rule will fire which either recalculates theexpected statistical behavior of any response packages of which thechanged user's response profile is an element, or determines if thenewly added or changed response profile should be added to an existingor a new response package. Inclusion of a response profile in a responsepackage may be based on a number of factors, including but not limitedto the geographic location of the facility (home or small business)associated with the new user (for instance, if all users within a givensubstation's service area are to be included in a single responsepackage), the demographics of the user (for instance, if a responsepackage comprised of “affluent greens” is maintained, and a new usermatching that profile is added), or the type of generation equipmentavailable at the new user's facility (for instance, if all wind powergenerators are bundled into a plurality of wind-based responsepackages). In this latter case, in an embodiment of the invention thewind profiles of the geographic locations of various users who togethercomprise a response package can be combined by statistics server 1030into a composite wind generation response package profile that can thenbe used to announce to prospective buyers the availability of specifiedamounts of wind power at specified times. In some cases, there may be aninsufficient number of response profiles in a given region, or of agiven type, to make a reasonably sized (and reasonably well-behaved,which typically is a consequence of having a statistically significantmix of response profiles in a single response package) response package;in these cases, when a new user or set of resources (associated with anexisting user) is added that is in the same region or has the same type,a rule is triggered which checks to see if there are now enough users,or enough load (or generating capacity) to create a new responsepackage. If the answer is yes, then a new response package is created,and a request is sent to statistics server 1030 to calculate theexpected responses of the new response package. When the results arereturned from the statistics server 1030, they are stored inconfiguration database 1022 and any rules for making the responsepackage available via communications interface 1320 are invoked. In thisfashion (and through the use of scheduled events as discussed above), aninventory of available response packages is made available to potentialbuyers on digital exchange 1000.

Another example of rules which are triggered by events according to theinvention is when a demand for service is placed at the digital exchange1000. In an embodiment of the invention, when a consumer's preference,stored in configuration database 1022, states that a given load shouldonly be operated when power of a certain type is available (forinstance, “don't run my dishwasher except using wind power”), and theconsumer desires to operate the given load, then a request is placed tothe digital exchange 1000 for a package of wind power of sufficientquantity to provide for the given load. The placement of such a requestconstitutes an event which is stored at event database 1020 and passedto rules engine 1031 to determine if any rules are fired by the event.In this case, a rule would be fired which determines if there is anywind power available in sufficient quantity to provide for the givenload. If not, a message is sent via communication interface 1320 to theappropriate remote iNode to so inform the user. If there is a singlesource of wind suitable for the given load, then the capacity of aresponse package associated with the source is decremented for therelevant time interval (it could be the current time interval or afuture time interval, for example when the given load is to be operatedaccording to a schedule at a future time) by an amount equal to theexpected demand from the given load. If there is more than one suitablesource available for the given load, then the rule that was invoked willeither resolve the situation itself if it is so designed, or it willinvoke a further rule to select from among a plurality of sources theone that is most appropriate. Selection of sources can be made accordingto any criteria, including but not limited to price, proximity to therequesting user, energy risk rating of the various response packages, ora fairness routine that spreads equally priced demand among a pluralityof sources of supply.

It should be appreciated that the examples of rules provided in theabove are exemplary only and should not be taken to limit the scope ofthe invention. Rules engine 1031 is the module that responds to eventsand that in effect creates an efficient market for energy based onaggregated response packages, which are in turn based on the detailedstatistical behaviors of a plurality of individual users, loads andenergy resources.

FIG. 11 illustrates a network architecture according to a preferredembodiment of the invention. A digital exchange 1100 acts as a controlpoint according to an embodiment. Users such as small businesses andconsumers participate by interacting with the digital exchange 1100.Interaction is normally conducted by connecting to the digital exchange1100 via the Internet 11011, although this is not necessary according tothe invention. Interaction between users and the digital exchange 1100can be conducted by any suitable communications medium, such as wired orwireless telephony. In various embodiments of the invention, usersinteract with the digital exchange 1100 through the use of mobile phones1122, personal computers (PCs) 1120, or a home area network (HAN) keypad1121 such as might be used as part of a home automation system. Whileaccording to a preferred embodiment of the invention interaction datasuch as preferences or requested actions are passed over the Internet1101 to and from users via one or more of these various devices, itshould be appreciated that web-based services can today be deliveredover a large and growing number of device types and communicationsnetworks without departing from the scope of the invention. Forinstance, a user could establish a multimodal voice-and-data sessionfrom a “smart mobile phone” over both the Internet 1101 and the wirelesstelephony network, and use both voice and data channels to interact witha digital exchange 1100 according to the invention. Furthermore, somemarket participants (that is, participants in an energy marketestablished according to the invention through a digital exchange 1100),such utilities or energy aggregators, may interact with a digitalexchange 1100 either directly or over the Internet 1101 from a marketinterface 1150. In some embodiments, market interface 1150 is adedicated server operating software adapted to communicate with thedigital exchange 1100 via hypertext transfer protocol (HTTP), extensiblemarkup language (XML) or a specialized protocol using XML, remoteprocedure calls (RPC), the SOAP web services protocol, or any of anumber of well-established data integration methods well-known in theart. Consumers and small business owners interact with a digitalexchange 1100 in order to identify and authenticate themselves, toidentify energy resources (for example, loads such as appliances,computers, hot tubs, etc., supply-side resources such as storage devicesor generators, although the invention should be understood to encompassany energy resources capable of being controlled by homeowners or smallbusiness operators), and to establish preferences concerning how andwhen any resources so identified are to be available actions requestedby the digital exchange 1100. Examples of preferences that might beexpressed according to the invention are levels of criticality of loads,minimum prices at which resources are to be considered available foruse, special times of day or particular days when specific resources (oreven all resources) are to be considered available for use (or to be notavailable for use). In general, the invention should not be consideredlimited to any particular set or sets of preferences, as any preferencesthat may be useful to a particular user or groups of users and that iscapable of being honored by a digital exchange 1100 are permissibleaccording to the invention. Users may also establish preferencesconcerning what amount of data concerning a user or his energy resourcesa digital exchange 1100 is allowed to retrieve, and under whatconditions (length of time, degree of anonymity, and the like) such datais to be allowed to be retained by a digital exchange 1100.

According to an embodiment of the invention, a home or small business1110 c comprises a plurality of electric loads 1130 that are connectedto, and draw electric power from, an electric grid 1160. At least someof loads 1130 are further adapted to communicate with a gateway 1111.Electric loads 1130 can be any kind of electric load capable of beingoperated in a home or small business, such as major appliances (washers,driers, and the like), electronics (computers, stereos, televisions,game systems, and the like), lighting, or even simply electric plugs(which can have any actual load “plugged into” it, or no load at all).In some embodiments, loads 1130 have current sensing and controlcircuitry capable of communicating with a gateway 1111 built in (forexample, “smart thermostats” and “smart appliances”, which arewell-known in the art); in other cases, loads 1130 may be connectedthrough wall sockets, surge suppressors, or similar switching devices,which are adapted to be able to communicate with a gateway 1111. In someembodiments, information about the current or power flowing through aload 1130 is passed to a gateway 1111. In other embodiments, onlyinformation about the status of the load, such as whether it is on oroff, is provided to a gateway 1111. Communications between gateway 1111and loads 1130 can be wireless, using a standard such as the ZigBeewireless mesh networking standard or the 802.15.4 wireless datacommunications protocol, or can be conducted using a wired connectionusing either power lines in the home or small business (broadband overpower lines) or standard network cabling. The actual data communicationsprotocol used between a gateway 1111 and a load 1130 may be any of theseveral data communications protocols well-known in the art, such asTCP/IP or UDP. According to an embodiment of the invention, a gateway1111 is connected via the Internet 1101 to a digital exchange 1100 usingan Internet Protocol (IP) connection; as with communications betweenuser interface devices and a digital exchange 1100, communicationsbetween a gateway 1111 and a digital exchange 1100 can be establishedusing any of the means well-known in the art, including but not limitedto HTTP, XML, SOAP, and RPC.

In an embodiment of the invention, a home or small business 1110 ccommunicates with a digital exchange 1100 via the Internet 1101 or asimilar data network. According to the embodiment, data is pushed from agateway 1111 to a digital exchange 1100 in order to provide informationconcerning condition of loads 1130. For example, gateway 1111, at aspecified time interval, may report to digital exchange 1100 that load1130 e is running and using 1.5 amps of current (or 180 watts of power),and that load 1130 f is off, and that load 1130 g is running inpower-conservation mode (for example, if load 1130 g is a computer andis adapted to provide its energy-management mode to a gateway 1111). Inother embodiments, gateway 1111 may pass periodic updates to digitalexchange 1100 and supplement the regular updates with event-basedupdates (for example, when a load 1130 f turns on). In yet otherembodiments, digital exchange 1100 pulls data from gateway 1111 eitheron a periodic basis or on an as-needed basis. It will be understood bythose having ordinary skill in the art that many combinations of pushand pull, periodic and event-driven update strategies may be used by oneor more gateways, or by a single gateway at different times, or indeedeven by a single gateway at one time, with different techniques beingused for different loads. Users in a home or small business 1110 c cancommunicate with the digital exchange 1100 as described above using a PC1120, a telephone such as a mobile phone 1122, a dedicated home areanetwork keypad 1121, or directly on gateway 1111, which canalternatively be equipped with a screen such as an LED screen or atouchpad, and optionally with buttons, sliders and the like forestablishing preferences that are then transmitted to the digitalexchange 1100.

According to another embodiment of the invention, a home or smallbusiness 1110 c comprises a plurality of electric loads 1130 that areconnected to, and draw electric power from, an electricity grid 1160,and further comprises a plurality of generation and storage devices 1140that are connected to, and adapted to provide power to, an electricitygrid 1160. At least some of loads 1130 and generators 1140 (taken hereto include storage devices that can provide electricity on demand to thegrid 1160) are further adapted to communicate with a gateway 1111.Electric loads 1130 can be any kind of electric load capable of beingoperated in a home or small business, such as major appliances (washers,driers, and the like), electronics (computers, stereos, televisions,game systems, and the like), lighting, or even simply electric plugs(which can have any actual load “plugged into” it, or no load at all).In some embodiments, loads 1130 have current sensing and controlcircuitry capable of communicating with a gateway 1111 built in (forexample, “smart thermostats” and “smart appliances”, which arewell-known in the art); in other cases, loads 1130 may be connectedthrough wall sockets, surge suppressors, or similar switching devices,which are adapted to be able to communicate with a gateway 1111. In someembodiments, information about the current or power flowing through aload 1130 is passed to a gateway 1111. In other embodiments, onlyinformation about the status of the load, such as whether it is on oroff, is provided to a gateway 1111. Electricity generators 1140 can beany kind of device capable of providing power to an electricity grid1160, including but not limited to wind turbines or other wind-drivengenerators, photovoltaic cells or arrays or other devices capable ofconverting sunlight into electricity, electricity storage devices suchas batteries and pumped hydro storage facilities, and the like.Communications between gateway 1111 and loads 1130 and generators 1140can be wireless, using a standard such as the ZigBee wireless meshnetworking standard or the 802.15.4 wireless data communicationsprotocol, or can be conducted using a wired connection using eitherpower lines in the home or small business (broadband over power lines)or standard network cabling. The actual data communications protocolused between a gateway 1111 and a load 1130 or a generator 1140 may beany of the several data communications protocols well-known in the art,such as TCP/IP or UDP. According to an embodiment of the invention, agateway 1111 is connected via the Internet 1101 to a digital exchange1100 using an Internet Protocol (IP) connection; as with communicationsbetween user interface devices and a digital exchange 1100,communications between a gateway 1111 and a digital exchange 1100 can beestablished using any of the means well-known in the art, including butnot limited to HTTP, XML, SOAP, and RPC.

In an embodiment of the invention, a home or small business 1110 ccommunicates with a digital exchange 1100 via the Internet 1101 or asimilar data network. According to the embodiment, data is pushed from agateway 1111 to a digital exchange 1100 in order to provide informationconcerning condition of loads 1130 and generators 1140. For example,gateway 1111, at a specified time interval, may report to digitalexchange 1100 that generator 1140 b is running and generating 500 wattsof power, and that load 1130 c is off, and that load 1130 d is runningin power-conservation mode (for example, if load 1130 d is a computerand is adapted to provide its energy-management mode to a gateway 1111).In other embodiments, gateway 1111 may pass periodic updates to digitalexchange 1100 and supplement the regular updates with event-basedupdates (for example, when a load 1130 c turns on). In yet otherembodiments, digital exchange 1100 pulls data from gateway 1111 eitheron a periodic basis or on an as-needed basis. It will be understood bythose having ordinary skill in the art that many combinations of pushand pull, periodic and event-driven update strategies may be used by oneor more gateways, or by a single gateway at different times, or indeedeven by a single gateway at one time, with different techniques beingused for different loads. Users in a home or small business 1110 d cancommunicate with the digital exchange 1100 as described above using a PC1120, a telephone such as a mobile phone 1122, a dedicated home areanetwork keypad 1121, or directly on gateway 1111, which canalternatively be equipped with a screen such as an LED screen or a.touchpad, and optionally with buttons, sliders and the like forestablishing preferences that are then transmitted to the digitalexchange 1100.

According to another embodiment of the invention, a home or smallbusiness 1110 b comprises a plurality of electric loads 1130 that areconnected to, and draw electric power from, an electric grid 1160 via aconnecting smart meter 1112 that is adapted to meter electricity usagewithin home 1110 b. At least some of loads 1130 are further adapted tocommunicate with a smart meter 1112. Electric loads 1130 can be any kindof electric load capable of being operated in a home or small business,such as major appliances (washers, driers, and the like), electronics(computers, stereos, televisions, game systems, and the like), lighting,or even simply electric plugs (which can have any actual load “pluggedinto” it, or no load at all). In some embodiments, loads 1130 havecurrent sensing and control circuitry capable of communicating with asmart meter 1112 built in (for example, “smart thermostats” and “smartappliances”, which are well-known in the art); in other cases, loads1130 may be connected through wall sockets, surge suppressors, orsimilar switching devices, which are adapted to be able to communicatewith a smart meter 1112. In some embodiments, information about thecurrent or power flowing through a load 1130 is passed to a smart meter1112. In other embodiments, only information about the status of theload, such as whether it is on or off, is provided to a smart meter1112. Communications between smart meter 1112 and loads 1130 can bewireless, using a standard such as the ZigBee wireless mesh networkingstandard or the 802.15.4 wireless data communications protocol, or canbe conducted using a wired connection using either power lines in thehome or small business (broadband over power lines) or standard networkcabling. The actual data communications protocol used between a smartmeter 1112 and a load 1130 may be any of the several data communicationsprotocols well-known in the art, such as TCP/IP or UDP. According to anembodiment of the invention, a smart meter 1112 is connected via theInternet 1101 to a digital exchange 1100 using an Internet Protocol (IP)connection; as with communications between user interface devices and adigital exchange 1100, communications between a smart meter 1112 and adigital exchange 1100 can be established using any of the meanswell-known in the art, including but not limited to HTTP, XML, SOAP, andRPC.

In an embodiment of the invention, a home or small business 1110 ccommunicates with a digital exchange 1100 via the Internet 1101 or asimilar data network. According to the embodiment, data is pushed from asmart meter 1112 to a digital exchange 1100 in order to provideinformation concerning condition of loads 1130. For example, smart meter1112, at a specified time interval, may report to digital exchange 1100that load 1130 e is running and using 1.5 amps of current (or 180 wattsof power), and that load 1130 f is off, and that load 1130 g is runningin power-conservation mode (for example, if load 1130 g is a computerand is adapted to provide its energy-management mode to a smart meter1112). In other embodiments, smart meter 1112 may pass periodic updatesto digital exchange 1100 and supplement the regular updates withevent-based updates (for example, when a load 1130 f turns on). In yetother embodiments, digital exchange 1100 pulls data from smart meter1112 either on a periodic basis or on an as-needed basis. It will beunderstood by those having ordinary skill in the art that manycombinations of push and pull, periodic and event-driven updatestrategies may be used by one or more gateways, or by a single gatewayat different times, or indeed even by a single gateway at one time, withdifferent techniques being used for different loads. Users in a home orsmall business 1110 c can communicate with the digital exchange 1100 asdescribed above using a PC 1120, a telephone such as a mobile phone1122, a dedicated home area network keypad 11211, or directly on smartmeter 1112, which can alternatively be equipped with a screen such as anLED screen or a touchpad, and optionally with buttons, sliders and thelike for establishing preferences that are then transmitted to thedigital exchange 1100. It will be appreciated that the description aboveof the communications associated with a home or small business 1110 dcomprising both loads and generators is equally applicable to homes orsmall businesses in which a smart meter 1112 is used in place of agateway 1111, with a smart meter 1112 performing similar functions to agateway 1112 in addition to its normal role of metering power usage.

In some cases, homes 1110 a may only pass aggregate electricityconsumption data to a digital exchange 1100 from a smart meter 1112,either via the Internet 1101 or a special-purpose data communicationsnetwork adapted for communications between smart meters 1112 andutility-based data systems. In these cases, even though there is novisibility at the digital exchange level to the individual loads andgenerators in homes 1110 a, it is still possible according to theinvention for a digital exchange to receive usage data (from smart meter1112) and to send requests for action (for instance, via a text messageto a mobile phone 1122 or even a phone call to a regular phone locatedat the home or small business 1110 a, asking the consumer to shedunnecessary loads due to high electricity demand or to attempt to placeany generating units online in response to a need at the electricitygrid 1160). Since any changes in load measured by smart meter 1112 athome or small business 1110 a would be sensed by digital exchange 1100shortly after the request went out, the response profile of such smartmeter-only users can be included in response packages according to theinvention. Even further, it is possible to include entirely unmonitoredloads 1131 and generators 1141 (again, taken to include storage systemscapable of injecting power onto the grid 1160); “unmonitored” as usedhere means that the usage of loads 1131 and generators 1141 is notmonitored in real time or near real time by digital exchange 1100. Theuse of unmonitored loads 1131 and generators 1141 can still bebeneficial according to the invention. For example, in an embodiment ofthe invention some users register unmonitored loads 1131 and generators1141 with the digital exchange 1100 using one of the user interfacemethods discussed earlier (for example, via a website associated withdigital exchange 1100). Optionally, the registering user can alsoprovide certified records of past operation of the unmonitored loads1131 or generators 1141, which can be used according to the invention asinput to be used in building a response profile for the unmonitoredloads 1131 or generators 1141. These unmonitored response profiles canbe included in larger response packages, with or without discounting ofthe capacity of the unmonitored loads 1131 or generators 1141 to accountfor the fact that these devices are unmonitored. Then, when a responsepackage including such unmonitored loads 1131 or generators 1141 isactivated, an activation message is sent to users of unmonitored loads1131 and generators 1141 advising them of the required action to take.Messages are sent via any communications medium, including but notlimited to phone calls, text messages, emails, or alerts on a websitethat may be monitored manually or automatically by users of unmonitoredloads 1131 and generators 1141. Accounting for whether such usersactually take the requested actions is done in two ways. First, thestatistical profile of the response profile for such energy resourceswill include the expected behavior (for example, the action will betaken 55% of the times it is requested); this is used by digitalexchange 1100 to build a response package that behaves as expected.Second, audits may be contractually required and conducted in whichactual usage of unmonitored loads 1131 and generators 1141 is checkedperiodically (for example, monthly), by a third party or with sufficientsafeguards against fraud as are needed to satisfy business needs of adigital exchange 1100. These needs will vary depending on the context.For example, some users of unmonitored loads 1131 and generators 1141will want to voluntarily participate and expect no remuneration fortheir participation; in these cases, it is not important to have a levelof confidence sufficient for the disbursement of funds, but only a levelof understanding of expected behaviors to enable a refinement of thestatistical model of the response profile. In other cases, users ofunmonitored loads 1131 and generators 1141 will expect to be paid fortheir participation, and therefore will likely agree to contractualterms including right of audit, for example of tamper-proof device usagelogs.

In another embodiment of the invention, one or more of loads 1130 aremonitored by “clip-on” current measuring devices which are clippedaround a load-bearing able in order to sense the current flowing throughthe cable. In an embodiment, the clip-on current sensor is adapted tomonitor one or more phases of the main current flowing into a home or asmall business, essentially acting (via its wireless connection to agateway 1111) as a clip-on smart meter.

It will be seen from the various embodiments illustrated in FIG. 11 thatessentially any arrangement of communications will suffice as long as itallows users of energy resources to establish their preferences, andoperators of digital exchange 1100 to build statistical models ofexpected responses to requests to take action, and operators of digitalexchange to send notification of requested actions to users of energyresources according to their preferences.

FIG. 12 shows a trading iNode 1200, according to an embodiment of theinvention. As with most intermediate iNodes, trading iNode 1200comprises a processor 1230 with software 1235 operating on it, and atleast one communications interface 1210. Communications interfaces 1210a and optionally 1210 b and others, are adapted to exchange data withone or more exchange iNodes 1210, which carry out functionssubstantially similar to those described with reference to digitalexchange 1100 in FIG. 11. Trading iNode 1200 will typically make heavyuse of transactional logic, and in most embodiments trading iNodes 1200will also comprise a local data store 1220. While trading iNode 1200 canbe implemented entirely within a single computer, in many embodiments itwill be preferable to use dedicated computers for one or more of localdata store 1220, communication interfaces 1210, and software 1235, andsome of these may even be provided in plural form for scalability orfault tolerance. When more than one computer is used in trading iNode1200, a data bus or local area network 1240 enables communicationbetween the various computers as is well established in the art. In someembodiments, network 1240 may in fact be the Internet or an intranet ofa trading firm or the like. Software of trading iNode 1200 in someembodiments may be adapted to perform analysis on electrical system dataprovided by one or more exchange iNodes 1210 or by external sources (notshown), such as paid information services. Other embodiments may includeautomated trading software 1235 operating on processor 1230 thatanalyzes data collected and stored in local data store 1220 (orexternally) and, based on these analyses and trading rules establishedby the user of trading iNode 1200, makes trades automatically when rulesor conditions are satisfied, on one more of exchange iNodes 1210.

FIG. 13 outlines a method, according to an embodiment, for incorporatingnew users into a digital exchange 1100. In a preferred embodiment, a newuser installs load iNodes 321 or source iNodes 322 in step 1300 tomeasure or manage one or more of the electrical resources under hercontrol. In a second step 1301 the user installs gateway iNode 310 andthe gateway, in step 1302, searches a local network foralready-installed child iNodes 803 (typically those installed in step1300). Once it has identified all of the installed iNodes that arevisible to it and (optionally) configured to be controlled by it, instep 1303 gateway iNode 310 registers with a parent iNode 802. In someembodiments, gateway iNode 310 will have an address for a parent iNode802 preconfigured in the device before it is distributed to users; inother embodiments users will have addresses of potentially relevantparent iNodes 802 available as part of the setup process. Typicallygateway iNode 310, on registering with parent iNode 802, will upload alist of the identities and types of any child iNodes 803 it detected instep 1301. After installing gateway iNode 310 (which performs steps 1302and 1303 autonomously under most embodiments, although this is notrequired), the user registers with digital exchange 1100, typically viaa website provided with installation instructions. In most embodiments,newly registering users will be asked by digital exchange 1100 (orservice provider 600, which could be any arbitrary third-party serviceprovider; in some embodiments users register with intermediaries whoparticipate in digital exchange 1100 on their behalf, without departingfrom the scope of the invention) to provide a serial number or otheridentifying information of the gateway iNode the user installed (in step1301); this information allows digital exchange 1100 or service provider600 to associate a human user with a set of iNodes (the gateway iNode310 and its associated child iNodes 303). In optional step 1304, notnecessarily performed immediately, a user is allowed to establish orprovide a series of preferences to digital exchange 1100 or serviceprovider 600, such as those discussed above concerning what demandmanagement actions the user will allow. Based on these preferences (or,in their absence, based on default settings which may be based on auser's demographic profile), an initial response profile for the user isestablished in step 1306, generally by digital exchange 1100, which mayhave received relevant user-specific data from service provider 600. Instep 1307, this response profile is optionally added by digital exchange1100 to one or more response packages, which modified response packagesmay then be made available by digital exchange 1100 to its participantsin step 1308.

All of the embodiments outlined in this disclosure are exemplary innature and should not be construed as limitations of the inventionexcept as claimed below.

1. A system for managing energy, comprising: a processor coupled to apacket data network; and a server software module executing on theprocessor; wherein the server software module is adapted to send andreceive information over a packet data network from a plurality ofclient software modules associated with energy load devices or energygenerating devices, at least some of said devices further associatedwith one or more end users of energy provided by an energy distributionnetwork; wherein the server software module is adapted to send andreceive information from a plurality of software modules associated withenergy distribution networks over the packet data network; wherein atleast some of the information sent from the server software module tothe software modules associated with energy distribution networks isbased at least in part on information received from one or more of theclient software modules and at least some of the information sent to theclient software modules is based at least in part on informationreceived from at least one of the software modules associated withenergy distribution networks.
 2. The system of claim 1, wherein theplurality of client software modules comprises iNodes adapted to senseand interrupt energy flow.
 3. The system of claim 1, wherein theinformation received from the plurality of client software modulesincludes at least information pertaining to the amount of energy beingconsumed by devices associated with respective client software modules.4. The system of claim 1, wherein the information received from theplurality of client software modules includes at least informationpertaining to desired attributes of energy to be consumed by devicesassociated with respective client software modules.
 5. The system ofclaim 1, wherein the information received from the software modulesassociated with energy distribution networks includes at leastinformation pertaining to attributes of energy distributed from theenergy distribution networks to the energy load devices associated withthe client software.
 6. The system of claim 1 wherein the informationreceived from the software modules associated with energy distributionnetworks includes at least instructions, directed to a plurality ofclient software modules associated with energy load devices or energygenerating devices associated with end users of the energy distributionnetworks sending the information, and pertaining to desired loadreductions or energy generation changes at the devices associated withthe client software modules.
 7. A method for managing energy, comprisingthe steps of: (a) receiving information via a packet data network fromclient software modules associated with energy load devices or energygenerating devices, at least some of said devices further associatedwith one or more end users of energy provided by an energy distributionnetwork; (b) receiving information via the packet data network fromsoftware modules associated with an energy distribution network; (c)sending information via the packet data network to at least one of thesoftware modules associated with an energy distribution based at leastpart on the information received from one or more of the client softwaremodules; and (d) sending information via the packet data network to aplurality of the client software modules based at least in part on theinformation received from one or more of the software modules associatedwith an energy distribution network.